OpenEdge Development:<br />ProDataSets Creating or defining the before-tables

For a dynamic temp-table, a before-table is created only when the temp-table’s TRACKING-CHANGES attribute (or the corresponding ProDataSet attribute) is first set to TRUE. After that the before-table remains in existence for the life of the after-table, even as TRACKING-CHANGES is set to FALSE and back to TRUE.

When you pass a ProDataSet parameter, if the receiving procedure receives the ProDataSet as a dynamic object (as a DATASET-HANDLE), then Progress automatically creates a before-table for each modified temp-table if one does not already exist.

In the case of a static temp-table that might be used to track changes as part of a ProDataSet, you must provide a static name for its before-table by naming it in the DEFINE TEMP-TABLE statement, as shown:

Syntax
DEFINE `TEMP-TABLE` `temp-table-name` [ BEFORE-TABLE `before-table-name` ] …

Progress cannot create a before-table for you at run time as it does for dynamic tables. Procedure code can refer to the before-table by name exactly as it does other temp-tables, except that any attempt to modify its records in any way results in a run-time error. For a static definition, the before-table is instantiated along with the after-table, and you can freely refer to it in procedural code. Until the temp-table is associated with a ProDataSet and TRACKING-CHANGES set to true for the after-table, the before-table simply is empty.

When you pass a ProDataSet parameter, if the receiving procedure receives the ProDataSet as a static object, then its static definition must include a static name for the before-table. Otherwise, Progress does not create a before-table and raises an error. Figure 6–1 shows how the before-table and after-table are related.

Actually, the before-table has a nonunique index on the ROW-STATE, so that changes are in order with delete operations first, then modify operations, then create operations.

Both the before-table and after-table are part of the ProDataSet. They are passed together as part of the ProDataSet parameter and have the same scope and lifetime, with the exception that a before-table for a dynamic temp-table is created only when first needed. The arrows illustrate the four states and relationships:

When OrderLine 09 is modified, the before image is copied to a new record in the before-table. The ROW-STATE for both records is ROW-MODIFIED, represented by the M in the illustration. The ROW-STATE is not actually stored as a user-accessible temp-table column. It is accessible only through the ROW-STATE attribute.

When row 11 is created, a placeholder for it is created in the before-table. It serves only to log the creation and point to the record in the after-table.

When row 22 is deleted, it is removed from the after-table and moved to the before-table.

Rows 10 and 77 have a ROW-STATE in the after-table of ROW-UNMODIFIED, represented by the U. There is no corresponding row in the before-table.